package com.tianjin.design.command;

/**
 * @Description: 命令模式# 行为型模式
 * 1、解释；将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。
 * 2、使用场景：命令模式将请求一个操作的对象与知道怎么执行一个操作的对象分隔开。我自己的理解是将行为的请求者与行为的实现者进行分离，降低耦合度，这时对行为
 *      进行记录、撤销、事务等操作就轻松了
 *      举个例子：客户有需求，如果直接和开发人员说，开发人员直接修改，但是，开发人员工作很多没办法立即修改，也有可能客户的需求又变更了，此类问题，
 *              如果行为的请求者（客户）与行为的实现者（开发人员）紧耦合，则会出现各种各样问题，所以这里用命令模式。
 *
 * 3、实现思路：基于上方客户与开发人员的关系
 *  3-1 客户的请求行为就是要做需求，而开发人员是具体的实现者，所以这里先抽象需求的请求对象（命令接口，需要执行命令），也就是行动定义 Command
 *          我理解的这里的命令接口好似是开发人员所在的公司，公司定义有哪些部门，每个部门做什么事情
 *          需要依赖接收者 Receiver
 *  3-2 抽象命令实现后，需要具体一个命令对象，这里声明 ConcreteCommand
 *          我理解的是明确开发部门，用来实现客户的需求
 *
 *       3-1、3-2 好比是颁发一系列命令，简单理解就是谁来做什么
 *
 *  3-3 任务还是需要具体的人做的，所以这里定义具体接收者 Receiver，明确接收者具体做的任务
 *  3-4  有了公司（命令），也知道了公司内部具体开发者的工作任务，此时还需要一个项目经理或者是部门经理来分配和管理这些任务，所以这里声明 Invoker
 *          这里的部门经理就比较轻松了，因为具体任务的接收者已经通过命令强制绑定，所以部门经理这里只需要“依令行事”即可，不需要在与具体实现者对话
 *  3-5 最后客户来任务了，部门经理只需要“依令行事”即可，如Test类中main
 *
 */
public class Test {

    public static void main(String[] args) {

        // 创建一个命令对象，并设定它的接收者，开公司，每个员工做什么事情，通过命令的方式绑定起来
        Receiver r = new Receiver();
        Command command = new ConcreteCommand(r);

        // 招一个部门经理
        Invoker invoker = new Invoker();

        // 部门经理收到客户的需求，只需要依令行事
        invoker.setCommand(command);
        invoker.executeCommand();

    }

}
